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(54) Reformatting with modular proxy server 



(57) A proxy server "platform" is provided that is 
easily modified and customized to reformat web content 
in a particular way under certain conditions as deter- 
mined by the operator of the proxy server. The proxy 
server retrieves from the Internet web content requested 
by a client, reformats it into a suitable format for the re- 
questing client, and then forwards the reformatted web 
content to the requesting client. The proxy server eval- 
uates operator-alterable rules to determine, based on 
capabilities of the requesting client (and/or on request 
variables), specifically how to reformat the requested 
web content so that it will be suitable for passing on to 
the requesting client. The platform has a "modular" ar- 
chitecture wherein content reformatting is performed by 



one or more "modules".. The modules are dynamically- 
linkable into the executing proxy server platform soft- 
ware at run time. The platform is easily customizable by 
the operator because modules can be deleted and/or 
added without affecting other modules. Modules are, in 
one embodiment, written in accordance with the COM 
modular programming standard so that individual mod-, 
ules can be removed, replaced and/or added without 
having to modify or recompile other modules. In one em- 
bodiment, web content cached on the proxy server is 
deemed suitable for passing to a requesting client if 
evaluation of the rules for the request from the client 
matches the prior evaluation of the rules that gave rise 
to the original reformatted web content as cached. 
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Description 

BACKGROUND INFORMATION 

[0001] Figure 1 (Prior Art) is a diagram of a system 1, 5 
known as the WebTV Network, that provides multiple 
WebTV clients 2-4 access to the Internet 5 via a WebTV 
server 6. WebTV clients 2-4 are WebTV set-top box In- 
ternet Terminals available from WebTV Networks Inc., 
of Mountain View : California. WebTV server 6 functions 10 
as a "proxy server" on behalf of clients 2-4 for purposes 
of accessing the Internet. Details of this WebTV Network 
including the proxy server are set forth in U.S. Patent 
No. 5,918,013, and U.S. Patent No. 5,935,207. 
[0002] In one operational example, client 2 attempts *5 
to access web content (for example, an HTML docu- 
ment) located on a remote server 7 of the Internet. Client 
2 issues a request Identifying the desired HTML docu- 
ment to WebTV server 6. If the. requested HTML docu- 
ment is stored in a proxy cache 8 on the WebTV server, 20 
then WebTV server 6 responds to client 2 by sending 
the requested HTML document as stored in its proxy 
cache 8 back to client 2. A browser on client 2 then 
renders the HTML document such that the document is 
displayed on the display of client 2. In this sense, 25 
WebTV server 6 is a proxy server. 
[0003] If, on the other hand, the requested HTML doc- 
ument is not present in proxy cache 8 , then WebTV serv- 
er 6 issues a request for the HTML document to remote 
server 7. Remote server 7 responds by sending the 30 
HTML document back to WebTV server 6. WebTV serv- 
er 6 in turn sends the HTML document to the client 2 
that initially made the request. The browser on client 2 
then renders the HTML document such that it is dis- 
played on the display of client 2. If the HTML document 35 
is a document that is likely to be accessed frequently by 
clients 2-4, then WebTV server 6 may store a copy 9 of 
the HTML document in proxy cache 8. 
[0004] WebTV server 6 also serves to reformat web 
content. In one example, client 2 attempts to access im- 40 
age data from remote server 7. The image data is, how- 
ever, in an image format inappropriate for client 2. The 
requested image data on remote server 7 is, for exam- ' 
pie, inappropriate in the sense that it is in a format that 
client 2 cannot decipher and display. Were client 2 to *5 
attempt to display this image data, client 2 would fail or 
would not be able to display the image. 
[0005] Alternatively, the image data is inappropriate 
in the sense that the image data is of higher resolution 
than is necessary. Client 2 may, for example, use a tel- so 
evision screen as a display device. An ordinary televi- 
sion generally has a lower pixel resolution than do many 
computer monitors. Because much of the image data on 
the Internet is for display on computer monitors, many 
images on the Internet have relatively high resolution 55 
image data which need not be transferred to the low res- 
olution displays of clients 2-4. 

[0006] If such inappropriate or unnecessary image 



data from remote server 7 were merely passed through 
WebTV server 6 in the same format, then client 2 would 
receive the inappropriate or unnecessary image data. If 
client 2 could not decipher the format, then client 2 may 
fail or not be able to display the image. If there were a 
large amount of high resolution image data that client 2 
cannot display, then the communication of the image da- 
ta to client 2 may take an unnecessarily large amount 
of time. 

[0007] WebTV server 6 therefore includes software 

10 called a "transcoder" that reformats the image data 
from the inappropriate format into an appropriate format. 
Client 2 first issues to WebTV server 6 a request for the 
image data on remote server 7. Assuming that the im- 
age data is not cached in proxy cache 8, WebTV server 
6 issues a request for the image data to remote server 
7. Remote server 7 responds by sending the image data 
in the inappropriate format to WebTV server 6. Trans- 
coder software 10 reformats Ihe image data into the ap- 
propriate format that client 2 can decipher. WebTV serv- 
er 6 then sends the reformatted image data to client 2. 
Client 2 can therefore access image data from the In- 
ternet even though that image data as it is available on 
remote server 7 on the Internet is not in a format that 
client 2 can decipher and display. 

[0008] Not only does WebTV server 6 reformat image 
data, but WebTV server 6 also reformats (i.e., "re- 
writes") the HTML of HTML documents. Consider a sit- 
uation in which the requested web content on remote 
server 7 is an HTML document that contains a "bug" or 
a "quirk". A bug may cause a browser of a client to fail. 
A quirk may cause a browser of a client to exhibit unde- 
sirable or unexpected features, even though the brows- 
er may not crash. WebTV server 6 therefore includes 
software 11 called an "HTML rewriter" that rewrites of- 
fending parts of the HTML to eliminate such bugs and 
quirks. 

[0009] In an operational example, client 2 issues to 
WebTV server 6 a request for a desired HTML docu- 
ment. Assuming that the desired HTML document is not 
cached in proxy cache 8, WebTV server 6 issues a re- 
quest forthe desired HTML document from remote serv- 
er 7. Remote server 7 responds by sending the HTML 
document with the bug or quirk back to the WebTV serv- 
er 6. Rather than sending the HTML document with the 
bug or quirk back to clients 2-4, HTML rewriter software 

11 reformats (rewrites) the HTML to eliminate the bug 
or quirk. The WebTV server 6 then sends the reformat- 
ted HTML document without the bug or quirk back to 
client 2 so that the browser on client 2 can render the 
HTML document without incident. 

[0010] HTML rewriter software 11 also functions to re- 
duce or eliminate a dead time ("perceived latency") 
sometimes experienced by a user of client 2. The brows- 
er in client 2 can start to render a web page involving an 
image if the browser has size information forthe image. 
If the browser has size information for the image, then 
the browser can begin to lay out the background page 
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leaving a blank of the appropriate si7e for the image data 
yet to arrive. If the browser does not have such size in- 
formation, then client 2 experiences a dead time ("per- 
ceived latency") from the time the request of the web 
page is made until the image data for the image is ac- 5 
tually received on the client and the browser begins to 
render the page. To avoid this perceived latency at the 
client, WebTV server 6 stores size information relating 
to the image in cache 8. When client 2 requests a web 
page involving an image, WebTV server 6 retrieves the 10 
size information from its cache, rewrites the HTML of 
the web page to include the size information, and then 
relays the HTML on to client 2. The browser in client 2 
can therefore begin to render the web page using the 
size information for any images on the web page when is 
it receives the HTML for the background page. The 
browser does not have to wait until it deciphers the 
HTML of the background page, identifies the image tag, 
issues a request for the image data identified by the im- 
age tag, and receives the actual image data with the size 20 
information. The size information is received along with 
the original HTML. The result of the rewriting of the 
HTML therefore results in a reduction in "perceived la- 
tency" at client 2. 

[0011] The code of WebTV server 6 presently com- 25 
mercially employed is a monolithic piece of code that 
typically supports clients of a single type (i.e. WebTV 
Internet Terminals running particular software). It is in- 
flexible and difficult to adapt and modify. For example, 
it is difficult to adapt the code to reformat content one 30 
way for requesting clients of a first type but to reformat 
content a second way for requesting clients of a second 
type. Such a modification would generally require rec- 
ompiling much or all of the WebTV server code. It would 
require an intimate knowledge of the inner workings of 35 
the WebTV server code. WebTV server 6 is therefore 
not considered to be well suited for operation, mainte- 
nance and customization by an independent operator 
(an operator other than WebTV that is not intimately fa- 
miliar with the inner workings of the monolithic code). A 40 
WebTV server platform is desired that can be operated 
by such an independent operator such that the operator 
can relatively easily modify, delete and/or add to part of 
the platform software without changing other parts of the 
platform software, and without having to have a detailed 45 
knowledge of the inner workings of the platform soft- 
ware. 

SUMMARY 

50 

[0012] A proxy server "platform" is provided that can 
be easily modified, customized, and maintained by an 
interactive television service operator (the "operator") 
not intimately familiar with the inner workings of the 
proxy server. The platform has a "modular" architecture 55 
wherein content reformatting is performed by one or 
more "modules".. The modules are dynamically-linkable 
into the executing proxy server platform software at run 



time. The operator can delete modules and/or add mod- 
ules to customize proxy server operation. In one embod- 
iment, the modules are written in accordance with the 
COM modular programming standard so that individual 
modules can be removed, replaced and/or added with- 
out having to modify or recompile other modules. Indi- 
vidual modules can have different authors. Modules can 
be written by .the operator, or by WebTV, or by another 
entity. Regardless of module author, the modules can 
be made to work together in the proxy server platform 
provided that the COM standard is followed in realizing 
the individual modules. 

[0013] In accordance with one aspect, the proxy serv- 
er uses information indicative of "client capabilities" of 
the requesting client to determine which modules will 
process the content before the content is relayed to the 
requesting client. A first client issues a first request to a 
proxy server for web content stored on a remote server. 
The first request contains information indicative of "cli- 
ent capabilities" of the first client (for example, the hard- 
ware capabilities of the first client and a software version 
number and software build number). The proxy server 
uses information indicative of the client capabilities to 
determine a first format appropriate for the first client. If 
the requested web content is cached on the proxy server 
in this first format, then the proxy server sends the web 
content to the first client. If the requested content is riot 
cached in the first format, then proxy server uses appro- 
priate modules to reformat the web content into the first 
format. Once reformatted, the web content is sent to the 
requesting first client. If the web content is not cached 
on the proxy server or if for some other reason the 
cached web content is not to be used (for example, it is 
too old), then the proxy server issues a request for the 
web content to the remote server, and retrieves the web 
content. If the web content is not in the first format, then 
the proxy server uses appropriate modules to reformat 
the web content into the first format. Once reformatted, 
the proxy server sends the web content back to the re- 
questing first client. 

[0014] Next, a second client having different client ca- 
pabilities from the first client issues a second request to 
the proxy server for the web content. The second re- 
quest includes information indicative of the client capa- 
bilities of the second client. The proxy server receives 
this second request and uses the information indicative 
of the client capabilities of the second client to determine 
a second format appropriate for the second client. 
[0015] If the requested web content is cached on the 
proxy server in this second format, then the proxy server 
sends the web content to the second client. If the re- 
quested content is not cached in the second format, then 
proxy server uses appropriate modules to reformat the . 
web content into the second format. Once reformatted, 
the web content is sent to the requesting second client. 
If the cached web content is not to be used (for example, 
it is too old), then the proxy server issues a request for 
the web content to the remote server, and retrieves the 



3 



BNSDOCID: <EP 1122654A2J_> 



5 



EP 1 122 654 A2 



6 



web content. If the web content as retrieved from the 
remote server is not in the second format, then the proxy 
server uses appropriate modules to reformat the web 
content into the second format. Once reformatted, the 
proxy server sends the web content back to the request- 
ing second client. It is therefore seen that the proxy serv- 
er determines the format in which the web content will 
be sent back to the requesting client based at least in 
part on information indicative of the client capabilities of 
the requesting client. 

[0016] In accordance with another aspect, the proxy 
server includes a first module and a second module. The 
first module reformats content the first way whereas the 
second module reformats content the second way. The 
first module, and not the second module, reformats the 
web content supplied to the first client. The second mod- 
ule, and not the first module, reformats the web content 
supplied to the second client. Each of the first and sec- 
ond modules is a portion of executable code thai is in- 
dependently dynamically-linkable into the proxy soft- 
ware at run time. 

[0017J In accordance with yet another aspect, the de- 
termination of the type of reformatted content to supply 
to a given requesting client is made using a set of oper- 
ator-alterable rules. First, the proxy server receives the 
information indicative of the client capabilities in the HT- 
TP header or form data of the request. The proxy server 
uses this information to look up a set of client capabilities 
from a look-up table or database. The client capabilities 
so determined are then in turn used as inputs for a sub- 
sequent evaluation of the operator-alterable rules. The 
evaluation of the rules determines, for a requesting cli- 
ent having particular client capabilities, which modules 
will process the requested web content and/or how 
those modules will process the requested web content. 
The rules are written in a relatively easy to understand 
textual form. The rules in this textual form are then read 
into the proxy server software such that the operation of 
the various modules is changed without modifying the 
code of the modules themselves. The operator need not 
have a detailed knowledge of the inner workings of the 
modules, to alter the rules, and/or to add or delete mod- 
ules. 

[0018] The modular reformatting software can be 
used by applications other than a proxy server applica- 
tion. In one aspect, an email server application uses the 
reformatting software to reformat email attachments 
from a first format unsuitable for a client to whom the 
email is addressed into a second format that is suitable 
for the client to whom the email is addressed. Due to the 
reformatting, the email client is able to read the email 
attachment where had the attachment not been refor- 
matted, the client could not read the attachment. The 
reformatting server uses information indicative of client 
capabilities of the email client that are passed to the 
server by the client to determine how to reformat the at- 
tachment so that it is in an appropriate format for the 
client. 



[0019] Other aspects of the invention and other em- 
bodiments are described in the detailed description be- 
low. This summary does not purport to define the inven- 
tion. The invention is defined by the claims. 

5 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0020] Figure 1 (Prior Art) is a diagram of a prior art 
network involving a proxy server that reformats content. 

10 [0021] Figure 2 is a diagram of a system 100 in ac- 
cordance with one aspect of the invention. 
[0022] Figure 3 is a flowchart of a method in accord- 
ance with an operation of the system 100 of Figure 2. 
[0023] Figure 4 is a flowchart of another method in ac- 

*5 cordance with an operation of the system 1 00 of Figure 
2. 

[0024] Figure 5 illustrates an operational example of 
the modular proxy server 1 08 of the system 1 00 of Fig- 
ure 2. 

20 [0025] Figure 6 is a diagram of an example of text file 
410 of rules. 

[0026] Figure 7 is a diagram of an operation of the 
tokenizer CRM of Figure 5. 

25 DETAILED DESCRIPTION 

[0027] Figure 2 is a diagram of a system 1 00 in ac- 
cordance with one aspect of the present invention. Sys- 
tem 100 includes a first interactive television network 

30 101 that includes a plurality of clients 102-104. Clients 
102-104 are coupled via client-to-server connections 
1 05-1 07 and a first modular proxy server 1 08 to the In- 
ternet 1 09. Client-to-server connections 1 05-1 07 can be 
of any suitable type including dial-up connections, ISDN 

35 connections, T1 connections, DSL connections, or ca- 
ble-modem connections. First proxy server 108 is oper- 
ated by a first operator. The users of clients 102-104 are 
customers of the first operator who typically pay the first 
operator for various services provided including the abil- 

40 ity of access the Internet 109 via first modular proxy 
server 108. In the example of Figure 2, first interactive 
television network 1 01 is the WebTV network and clients 
1 02-1 04 are WebTV set-top Internet Terminals available 
from WebTV Networks, Inc. of Mountain View, Califor- 

45 nia. The operator of first proxy server 108 is therefore 
WebTV Networks, Inc. of Mountain View, California. For 
additional information on a WebTV set-top box Internet 
Terminal see: U.S. Patent Application Serial No. 
. 09/295,746 and U.S. Patent Application Serial No. 

50 09/238,133 (the subject matter of these applications is 
incorporated herein by reference). For additional gener- 
al information on a proxy server of the structure and op- 
eration of a client-server interactive television network, 
see: U.S. Patent No. 5,918,013 and U.S. Patent No. 

55 5,935,207 (the subject matter of these patents is incor- 
porated herein by reference). 

[0028] In accordance with one aspect of the present 
invention, a second interactive television network 11 0 is 
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provided wherein the software on proxy server 111 of 
the second network 110 shares a high degree of com- 
monality with the software on proxy server 1 08 of the 
first network, but wherein the second network 1 1 0 is op- 
erated by a second operator. The software of proxy serv- 
er 1 08 of the first network 1 01 and the software of proxy 
server 111 of the second network 110 is an adaptable 
and customizable modular software platform, the soft- 
ware platform being adapted and customized a first way 
for operation as first proxy server 108 in first network 
101 , the software platform being adapted and custom- 
ized a second way for operation as second proxy server 
111 in second network 110. 

[0029] Even though the same platform software is ex- 
ecuted on proxy servers of the two networks 101 and 
110, the two networks are separate and different net- 
works from the perspective of the users of the two net- 
works. The commonality of the internal workings of the 
proxy servers of the two networks is not readily apparent 
to the users of either of the two networks. The users of 
second network 110 are customers of the second oper- 
ator, not of the first operator. In the example of Figure 
2, clients 112-114 are interactive television Internet ter- 
minals of different make and construction than clients 
102-104. Clients 112-114 are coupled via connections 
11 5-1 17 and second modular proxy server 1 1 1 to the In- 
ternet 109. 

[0030] Figure 3 is a flowchart of a method in accord- 
ance with an operation of the system 100 of Figure 2. 
Clients 1 02-1 04 of the first network 1 01 are clients that 
can best utilize web content on a remote server 118 
when that web content is provided in a first format. Cli- 
ents 112-114 of the second network 110, on the other 
hand, are clients that can best utilize the web content 
on the remote server 1 1 8 when that web content is pro- 
vided in a second format. 

[0031] In one example, the displays of clients 1 02-1 04 
are of a smaller resolution than are the displays of clients 
112-114. The web content on remote server 118 is im- 
age data for an image, the image data being of higher 
resolution than can be displayed on the displays of ei- 
ther clients 102-104 or clients 112-114. Accordingly, to 
reduce the amount of image information that needs to 
be transferred to a client that requests the image data, 
a greater reduction in the amount of image data is per- 
formed where the image data is to be supplied to clients 
102-104 than where the image data is to be supplied to 
clients 112-114. A first dynamically-linkable image- 
reformatting module (MODULE 1) that was originally 
provided along with the modular proxy server software 
platform performs the appropriate amount of reduction 
for clients 1 02-1 04. The first operator of first network 1 01 
therefore uses this MODULE 1 to reformat the image 
data. The image data is, however, reformatted for the 
clients 112-1 1 4 of the second network 1 1 0 using a cus- 
tom dynamically-linkable image-reformatting module 
(MODULE 4) that is specially written for this purpose by 
the second operator. The original image-reformatting 



module (MODULE 1) supplied with the platform has 
been removed from second proxy server 111, and the 
specially-written MODULE 4 has been substituted! The 
two modules (MODULE 1 and MODULE 4) are dynam- 
5 ically-linkable modules written in accordance with the 
COM programming standard. 

[0032] In a first step 200 (see Fig. 3). the first modular 
proxy 108 receives: 1 ) a request from first client 1 02 for 
the web content on remote server 118, and 2) informa- 

10 tion indicative of client capabilities of the first client. The 
information indicative of client capabilities may, for ex- 
ample, be contained in the header or form data of the 
HTTP request. The information indicative of client capa- 
bilities may be client capabilities passed to the proxy 1 08 

15 by the client, or the information indicative of client capa- 
bilities may be other information that is usable to deter- 
mine client capabilities. In this example, the information 
is information indicative ofthe particular resolution of the 
display (a browser type, software version number, and 

20 a software build number) of first client 1 02. it is not the 
resolution of the display, although it could be in some 
embodiments. 

[0033] In a second step 201 , the first modular proxy 
1 08 uses this information indicative of tho capabilities of 

25 client 102 to determine to reformat the requested web 
content using its image-reformatting module (MODULE 
1). From the information indicative of client capabilities, 
the first proxy 108 in this example determines that the 
first client has a display of a particular resolution and 

30 therefore is best provided with image data reformatted 
by MODULE 1. If the requested web content is not 
present on the first proxy 108, then the first proxy 108 
issues a request to the remote server 118 for the web 
content. The remote server 118 responds by sending 

35 the requested web content (in this case, image data) 
back* to the first proxy server 108. 
[0034] Next (step 202), the first proxy server 108 
reformats the web content into first reformatted content 
using the first module (MODULE 1 ) and not using a sec- 

40 ond module (MODULE 4). In this example, the first refor- 
matted content is of appropriate resolution for the dis- 
play of client 1 02. The first proxy server 1 08 then (step 
203) sends the first reformatted content back to the re- 
questing first client 1 02. 

45 [0035] Next (step 204), the second modular proxy 
server 111 of the second network 110 receives: 1) a re- 
quest from a second client 112 for the web content on 
remote server 118, and 2) information indicative of the 
client capabilities of the second client 1 1 2. In this exam- 

50 pie, the information is contained in the header of the re- 
quest and is indicative of the resolution of the display of . 
the second client 112. 

[0036] Next (step 205), the second modular proxy 
server 111 uses the information indicative of the client 
55 capabilities of second client 1 1 2 to determine to reformat 
the requested web content using a second module 
(MODULE 4). In this example, the second module refor- 
mats the requested image data to have an appropriate 
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resolution for the resolution of the display of second cli- 
ent 112. If the requested web content is not present on 
second proxy server 111 , then second proxy server 111 
issues a request for the web content to the remote serv- 
er.1 1 8. Remote server responds by sending the request- 5 
ed web content back to the second proxy server 111. 
The second modular proxy server 111 then reformats 
(step 206) the web content into second reformatted con- 
tent using the second module (MODULE 4) and not us- 
ing the first module (MODULE 1 ). The second modular io 
proxy 111 then supplies (step 207) the second reformat- 
ted content to the second client 112. It is therefore seen 
that the first instance of the proxy server platform in a 
first network 101 reformats the requested web content 
using a particular module (MODULE 1), whereas the is 
second instance of the proxy server platform in a second 
network 110 reformats the very same requested web 
content using a different module (MODULE 4). 
[0037] Figure 4 is a flowchart of anoLher method in ac- 
cordance with an operation of the system 1 00 of Figure 20 
2.. In this method, web content is formatted in different 
ways within the same interactive television network de- 
pending on the different client capabilities of the re- 
questing clients. 

[0038] In a first step (step 300), modular proxy server 25 
108 receives a request from a first client 102 for web 
content on remote server 1 1 8. The modular proxy server 
108 also receives (step 301) from first client 102 infor- 
mation indicative of client capabilities of the first client 
102. The information indicative of client capabilities is, 30 
in this example, present in the header of the request and 
indicates that first client 1 02 is enabled to handle com- 
pressed image data in a first compression format. 
[0039] Next (step 302), modular proxy server 1 08 us- 
es the information indicative of client capabilities to de- 35 
termine to reformat the requested web content using, a 
first module (MODULE 1 ). This first module may, for ex- 
ample, reformat the image data into compressed image 
data in the first compression format. 

[0040] If the requested web content is not present on 40 
proxy server 108, then proxy server 108 issues a re- 
quest for the web content to remote server 118. Remote 
server 1 1 8 responds by sending the requested web con- 
tent back to proxy server 1 08. Modular proxy server 1 08 
then reformats the web content (step 303) into first refor- *s 
matted content using the first module. (MODULE 1 ) and 
not using a second module (MODULE 3). In this exam- 
ple, the first reformatted content is image data in the first 
compression format. Once generated, this first refor- 
matted content is supplied (step 304) back to the re- so 
questing first client 102. The image data is therefore in 
the first compression format preferred by the first client 
102. 

[0041 ] Next, the modular proxy server 1 08 receives a 
request from a second client 103 of the network 1 01 for 55 
the same web content on remote server 118. The mod- 
ular proxy server 108 also receives (step 306) informa- 
tion indicative of client capabilities of the second client 



1 03. Again, this information may be present in the head- 
er of the request, 

[0042] Modular proxy server 108 then uses the infor- 
mation indicative of client capabilities of the second cli- 
ent 103 to determine to reformat the web content using 
the second module (MODULE 3). The requested web 
content, having already been retrieved by the proxy 
server 1 08, is likely cached in its original form (as stored 
on remote server 1 1 8) in cache 1 1 9 of server 1 08. If the 
web content so cached is not too old, then proxy server 
108 uses this content and does not need to retrieve the 
web content from the remote server 118. Otherwise, 
proxy server 108 issues a request to remote server 118 
for the web content. Remote server 118 responds by 
sending the requested web content back to proxy server 
108. 

[0043] Next (step 308), modular proxy server 108 
reformats the web content into second reformatted con- 
tent using the second module (MODULE 3) and not us- 
ing the first module (MODULE 1). The second module 
in this example reformats image data into compressed 
image data in a second compression format preferred 
by second client 103. Once the second reformatted con- 
tent is generated, the modular proxy server 108 supplies 
(step 309) the second reformatted content to the second 
client 103. Accordingly in this method it is seen that the 
modular proxy server reformats the web content one 
way using a first module when the web content is re- 
quested by a first client having first client capabilities, 
but reformats the same web content a second way using 
a second module when the web content is requested by 
a second client having second client capabilities. The 
first client may, for example, be an unsophisticated de- 
vice (for example, a PalmPilot, a personal organizer, or 
a cellular telephone) that does not have the ability to 
decode a compressed format of the second type. The 
second client may, for example, be a WebTV Internet 
Terminal that does have the ability to decode a com- 
pressed format of the second type. 
[0044] Figure 5 illustrates an operational example of 
modular proxy server 1 08 where client 1 02 requests an 
HTML web page which in turn contains an image. The 
image data for the image is of higher resolution than can 
be displayed on the screen of the requesting client 1 02. 
The HTML image tag for the image does not contain size 
information for the image so the above described "per- 
ceived latency" problem associated with rendering the 
background page would be experienced on client 102 if 
the HTML were forwarded to the client without the miss- 
ing size information. 

[0045] Modular proxy server 108 includes a proxy 
server application 400, a content reformatting (CRF) ob- 
ject 401, multiple content reformatting module (CRM) 
objects 402-405, and a CRF administration configura- 
tion interface system (CACIS) 406. CRF 401 controls 
the content reformatting process. CRF 401 has an as- 
sociated configuration object 407 which stores informa- 
tion about how content reformatting is to be done on that 
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particular server. This information includes a set of rules 
408 and a list 409 of the CRMs (and any sub-CRMs) 
present. 

[0046] The rules 408 are entered into CACIS 406 by 
the operator in either text form as a human-readable text 5 
file 41 0 or via a graphical user interface (GUI) 41 1 . CA- 
CIS 406 in turn loads the rules into the rules portion 408 
of configuration object 407. Each rule has a condition 
(set of boolean expressions) and a resultant expression. 
The resultant expression is a list of CRMs (usually only 10 
one but there could be several) with the input parame- 
ters to pass to each CRM. All rules that evaluate to 
TRUE are executed and the order of execution of the 
rules follows the order the rules as they appear in text 
file 410. 15 
[0047] Figure 6 is an example of text file 410. When 
proxy server 108 is initialized, CACIS 406 reads text file 
410 and then loads the rules into the rules portion 408 
of the configuration object 407. The CACIS 406 also 
loads the list 409 with a list of the CRMs 402-405 that 20 
are present. 

[0048] The rules 408 are evaluated at run time using 
request variables and/or client capabilities as inputs. 
Request variables include content-length, content-type 
and user-agent. (Even though the content-length and 
content-type do not directly come from the request itself 
but rather come from the response to the request, they 
are nonetheless considered "request variables" be- 
cause they relate to the request in the sense that they 
describe the information requested by the request.) The 
client capabilities are operator extensible. For each var- 
iable there are acceptable values or ranges of values. 
[0049] Although client capabilities can be passed 
from the client to the proxy server in the request in some 
embodiments, the client capabilities are in the presently 
described embodiment determined by the proxy server 
application 400 using a client-capabilities database 
(CCD). Information indicative of client capabilities (for 
example, a browser identifier for the browser executing 
on the requesting client, a software version number of 
the browser software, and a software build number of 
the browser software) received from the requesting cli- 
ent is used to look up corresponding client capabilities 
of the requesting client. In the present example, a 
browser identifier, a software revision number, and a 
software build number are present in the header of the 
request as received from client 102. The information is 
of the form: WebTV-1 .2-XXXX. The "WebTV" portion is 
the browser identifier. Other possibilities include "Net- 
scape" and "Mozilla". The "1 .2" portion is the software 
revision number. The "XXXX" portion is a four digit soft- 
ware build number. In the present example, proxy server 
application 400 determines from this information indic- 
ative of client capabilities that client 102 has particular 
values for each of the following "client capabilities": dis- 
play resolution in the x dimension (the horizontal dimen- 
sion): display resolution in the y dimension (the vertical 
dimension); color scheme; bit depth; connection speed; 



type of connection; amount of memory, amount of cache 
memory, amount of disk space; processor speed; image 
formats supported; audio formats supported; whether 
the client supports stereo audio or just mono audio. 
[0050] Once the client capabilities and the request 
variables (content length, content type, and user agent) 
are known for the particular request, proxy server appli- 
cation 400 calls the method "CreateNewContext" 415 
using this information as inputs in order to create a con- 
text object (CTX) 413 for the new transformation. (The 
term "transformation" here is used to denote the refor- 
matting operation.) CRF 401 then queries the new CTX 
41 3, obtains the interface pointer (a handle to CTX 413), 
and gives it to the proxy server application 400. Once 
created, CTX 413 is the object that proxy server appli- 
cation 400 communicates with. 

[0051] In this example, the requested HTML docu- 
ment is not cached in cache 414. Proxy server 108 
therefore issues a request for the HTML document to 
remote server 118. Remote server 118 responds by 
sending the HTML back to proxy server 108. As the 
HTML (data) begins to stream back into the proxy server 
1 08, the proxy server application 400 calls a "PushData" 
function 41 6 on CTX 413 with an indicator. The indicator 
either indicates that more data will be coming later (as 
in the case of data streaming), or that all the data has 
now been pushed to the context. CTX 413 uses a refer- 
ence to configuration object 407 to cause an evaluation 
of the rules 408 using the determined client capabilities 
and request variables. The result of this rule evaluation 
is: 1) an ordered list of the CRMs that will be used to 
process the HTML where the order indicates the order 
in which the CRMs will be used, and 2) input control pa- 
rameters for each CRM that control how the CRM will 
perform. Operation of an individual CRM is controlled 
by the input control parameters passed to it. 
[0052] The CRMs used for processing the HTML in 
this example is a page patcher CRM 402 and a tokenizer 
CRM 403. One of the input control parameters to the 
page patcher CRM 402 is a list of structures, each of the 
structures defining a particular page patch that is to be 
performed. The tokenizer CRM does not receive any in- 
put control parameters. 

[0053] CTX 413 goes to the first CRM in the ordered 
list and creates a state (not shown) by calling Creat- 
eNewState on the CRM. (There is a new state for every 
operation carried out by a CRM). CTX 413 then passes 
the appropriate input control parameters to that CRM 
and calls the function "process data" 417 on the state. 
In this example, the first CRM in the ordered list is page 
patcher CRM 402. If the client 102 is known to have 
problems with a particular HTML sequence, then the 
page patcher CRM 402 looks for that particular offend- 
ing sequence in the HTML and replaces it with an ac- 
ceptable sequence. That data then goes back 418 to 
CTX 413. CTX 413 proceeds to the next CRM in the 
ordered list (which in this case is the tokenizer CRM 
403), creates a state (not shown) on tokenizer CRM 403, 



30 



35 



40 



45 



50 



7 



1122654A2_I_> 



"13 



EP 1 122 654 A2 



14 



and calls 419 the function "process data" on the token- 
izer state. 

[0054] In the present example, the image tag on the 
HTML web page as received from remote server 118 
does not have image size information. Accordingly, cli- 5 
ent 102 will experience a "perceived latency" if it were 
to try to render the background page as the HTML is 
received on the client 1 02 because the client would not 
at that time have the size information for the image. If, 
on the other hand, the HTML contained the size infor- 
mation then client 102 could start to render the back- 
ground page using the size information in the image tag 
before the client had actually received the image data 
itself. To eliminate this "perceived latency" in the render- 
ing of the background page, tokenizer CRM 403 inserts 
the size information into the HTML before the HTML is 
passed back to client 102. 

[0055] Accordingly, the tokenizer state searches 
through the HTML lags for the image lag, obtains Ihe 
image name from the image tag, uses the image name 
to look in cache 41 4 for the size information for that par- 
ticular image that has been previously stored, and then 
adds characters H=_ W=_ into the stream of HTML at 
the appropriate place so that the HTML image tag indi- 
cates the size of the image. 

[0056] Figure 7 is a diagram of this operation of to- 
kenizer state 500. The tokenizer state 500 does not do 
a transformation itself, but rather uses a tokenizer 501 
to convert a stream of HTML text 502 into a stream of 
conceptual tokens 503. These tokens 503 are passed 
through a series of tokenizer sub-modules 504 and 505 
that modify, insert, remove, and/or reorder the tokens. 
The set of tokenizer sub-modules is operator modifiable 
in the same way the set of CRMs is. In this example, 
tokenizer sub-module 504 passes the image name 506 
from the image tag to cache 414. This image name iden- 
tifies the stored size information (height and width) for 
the image which is returned 507 to the sub-module 504. 
This size information is then inserted to create an ap- 
propriately modified token stream 508. This modified to- 40 
ken stream 508 is then converted into a modified HTML 
text stream 509 by a detokenizer 510 of the tokenizer 
state 500. This modified HTML is then passed back 
509,420 to CTX 413. 

[0057] When CTX 413 gets the HTML data back, it 45 
causes rules 408 to be evaluated again. It then returns 
from the "PushData" function call and passes 421 the 
modified HTML (that now includes the image size infor- 
mation and has had malformed or quirk-causing HTML 
removed) back to proxy server application 400. The re- so 
quested HTML is then passed back to the requesting 
client 102. Client 102 receives the HTML and begins to 
render the background page using the size information 
in the image tag. Client 1 02 begins to render the back- 
ground page before it has received or even requested 55 
the actual image data itself. The above-described "per- 
ceived latency" problem is therefore solved. 
[0058] Client 1 02 then issues a request for the image 



data to proxy server 108. Proxy server 108 examines 
cache 414 and determines whether the image data is 
cached there. If the image data is cached, then proxy 
server 1 08 returns the image data reformatted as ap- 
propriate based on the determined client capabilities. 
Multiple versions of the image may be cached, the one 
of these version that is appropriate for the requesting 
client is determined by the client capabilities. Alterna- 
tively, only one version of the image data is cached, and 
this version is reformatted as necessary. The client ca- 
pabilities are used to determine how the reformatting 
should be done for the requesting client. 
[0059] In the present example, the proxy server 108 
does not have the requested image data cached. Proxy 
server 1 08 therefore issues a request for the image data 
from the remote server 118.. When remote server 118 
responds with the image data, proxy server 108 creates 
another context by passing in the content-length, con- 
lenl-lype, user-agenl and client capabilities for the im- 
age data request. Proxy server application 400 then 
calls the "PushData" function on the context and evalu- 
ates the rules to generate a list of CRMs to use and for 
each listed CRM a set of input control parameters. In 
this example, all image reformatting is performed by one 
CRM, the image CRM 404. CRM 405 performs audio 
reformatting. 

[0060] In this example, the image data as received 
from remote server 1 1 8 is of higher resolution than can 
be displayed on the display of the requesting client. A 
new state of the image CRM 404 is created using input 
parameters that cause the image CRM 404 to output 
image data of appropriate resolution for the display of 
the requesting client 1 02. The context passes the image 
data into the image CRM state, and receives the proc- 
essed image data back. The context returns from the 
"PushData" function call by sending processed image 
data (now of appropriate resolution for the display of the 
requesting client 102) to proxy server application 400 
which in turn passes the image data back to requesting 
client 102. Client 102 uses the image data to fill in the 
blank space left in the background page for the image, 
thereby rendering the completed web page. Image data 
can be processed as a series of chunks, with each indi- 
vidual chunk being processed through the proxy server 
application, the context and the appropriate CRMs, and 
back to the proxy server application as described above 
thereby facilitating slreaming. 

[0061] When the reformatting is finished, the method 
DeleteContext is called by the proxy server application 
400. Because the context follows a reformatting opera- 
tion through from beginning to end, it is possible to store 
transformation statistics (total computation time, mean- 
square-error, and interesting conditions) in the context 
for the proxy server application 400 to use. For that rea- 
son, the proxy server application 400 is in complete con- 
trol of the lifetime of a context. 
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THE CRM 

[0062] The CRMs do the specialized work involved in 
a content transformation. There is one instantiation of 
each CRM per machine, although multiple threading al- 
lows the same instance to be working on multiple trans- 
formations simultaneously. Four CRMs are provided 
with the standard proxy server platform. The first CRM 
is a page patcher. The second CRM is a tokenizer. The 
third CRM handles image transformations and supports 
data streaming. The fourth CRM handles audio trans- 
formations and supports data streaming. The behavior 
of these CRMs is modifiable via a set of input control 
parameters specific to each CRM. Selection of these in- 
put control parameters on a per request basis is done 
by evaluating the rules 408. Each CRM designer should 
publish a list of supported, input control parameters 
(probably in an XML file) along with their default values 
and acceptable ranges if the CRM is to be included in 
the rules 408. These input control parameters in many 
cases give operators all the flexibility they need without 
having to write their own CRMs. However, in the event 
that very specialized processing need occur (for exam- 
ple to workaround a bug found in a specific client), the 
operator has the option of writing custom CRMs (custom 
CRMs and custom sub-CRMs). These custom CRMs 
may either precede, follow, or replace the CRMs sup- 
plied with the platform. The CRMs present are listed in 
list 409. The operator can add CRMs to list 409.. The 
operator can also delete CRMs from list 409. 
[0063] Because streaming CRMs like the audio mod- 
ule may be invoked multiple times before a transforma- 
tion is complete, temporary storage of state information 
is requisite. This state information is stored in a module 
state object and is kept in the context itself. Streaming 
transformations also create the possibility that multiple 
CRMs may be working on different parts of a data 
stream simultaneously. Therefore the context actually 
holds a list of module states which are accessed with a 
CRM identifier (either an assigned ID or the CRM's 
pointer). Similarly, buffering is done on a per CRM basis, 
and these buffers are stored in the module states. 
[0064] The CRM interface involves four functions: 
DigestParams, CreateNewState : DeleteState, and Ini- 
tialize. 

[0065] HRESULT DigestParams ([in] RawParamType 
rawParams, [out] IWtvCRMParamType" digParams). 
This function "DigestParams" is called when the rules 
are compiled at proxy server 1 08 initialization, and when 
the rules 408 are changed with the CACIS interface 406. 
The raw textual input control parameters may be a sim- 
ple semi-colon delimited string of tag value pairs, some 
other structure, or they may be looked up individually in 
some other way by the CRM. The CRM parses the raw 
input control parameters and converts those raw input 
control parameters into a compact and optimized struc- 
ture whose form is known only to itself and its module 
state. This optimized format is known as the digested 



parameters and is returned to the CRF configuration ob- 
ject via a generic COM interface pointer. In this way, the 
framework can demand certain base-level functionality 
from the digested parameters (like dumping their con- 
5 tents to a log) without dictating or knowing exactly what 
their internal structure is. These digested parameters 
are stored with the CRM pointers in the internal repre- 
sentation (rule trees) of the rules in the rules portion 408 
of the configuration object 407. Every time a content 
10 transformation is initiated, the digested parameters are 
used rather than the raw parameters. Therefore the 
work of parsing, compressing, optimizing, and bound 
checking the input parameters is done only once for 
each rule upon system start up. 
15 [0066] HRESULT CreateNewStates din] IWtvCRM- 
ParamType* params, [in) IWtvCRFContexf context, 
[out] IWtvCRMStates" moduleState). This function is 
called by the context once for each CRM involved in a 
transformation. The context then interacts with the mod- 
20 U le state to process the data. CRMs store the parame- 
ters in the module state for reference across multiple 
invocations on the same transformation. 
[0067] HRESULT DeleteState ([in] IWtvCRMState* 
moduleState). This function is called when a transfor- 
ms mation has finished and the CRM's state information is 
not longer needed. 

THE CRM STATE 

30 [0068] The CRM state is a necessary object because 
data arriving is often times processed in chunks. The 
context needs a way to store the state of a CRM's work 
(for example, parameters and temporary data) while 
waiting for new data to arrive. The CRMState itself does 

35 the work of the transformation (although it can be viewed 
as an internal component of the CRM, as is done in Fig- 
ure 5). The CRMState interface has four functions: Proc- 
essData, IsStreaming, MinimumlnputData, GetSpool, 
and GetStats. The data is pushed through the CRM- 

^0 State by the Context and returned to the context with 
ProcessData. The context uses the two functions 
"IsStreaming" and "MinimumlnputData" to determine 
how best to buffer the incoming data. Partial incoming 
data is given to the CRMState only if it can stream and 

^5 jf the amount of data available exceeds the minimum 
input data for streaming. Otherwise, the context buffers 
the data until more arrives. GetSpool is a way to avoid 
unnecessary data copying between the context and 
module state. In essence, they share the same data ar- 

50 ea in an efficient manner. GetStats is a way for the con- 
text to cull generic statistical information from the mod- 
ulo state even though the context does not know what 
sort of specific transformation is being done by the mod- 
ule state. The statistics are returned to the context via 

55 a generic COM interface pointer which dictates certain 
minimum requirements for the statistics structure (for 
example, outputting its contents to a log file). Hence, the 
platform software is able to calculate metrics and/or 
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warehouse content transformation statistics, even for 
transformations written by platform operators or third 
party software vendors. 

THE CONTEXT 5 

[0069] The context records information for a particular 
transformation including the original and current request 
variables, module states, and buffered input data. Be- 
cause the data is often received by the server in chunks, 10 
a transformation may be suspended until more data is 
available. The context records which CRMs are working 
on a data stream. If those CRMs are streaming, then the 
context immediately passes the data to the CRMs for 
processing. For non-streaming transformations, the 15 
context buffers the data for the CRM until the 
STREAM_END indicator is received. At that point, the 
context calls the CRM for processing. 
[0070] The context keeps track of CRMs involved in 
a transformation by maintaining the CRM list generated 20 
by evaluation of the rules 408 when the transformation 
begins. This list contains pointers and a flag for each 
pointer which the context must update as the transfor- 
mation proceeds. The flag may have the following val- 
ues: 1) Value WTV_CRM_ACTIVE which means that 25 
the CRM is working on the data stream but is suspend- 
ed; 2) Value WTV_CRM_FINISHED which means that 
the CRM has completed its work on the stream or whole 
data set; and 3) Value WTV-CRM_PENDING which 
means that the CRM is scheduled for future invocation. 30 
[0071] The list produced by evaluation of the rules 408 
is a function of the request variables and/or client capa- 
bilities. The client capabilities are determined by the 
proxy server application (the proxy server can deter- 
mine the client capabilities from information indicative 35 
of client capabilities, or the client capabilities them- 
selves may be passed from the client to the proxy serv- 
er) and remain constant throughout a transformation, 
but some of the request variables (namely content-type 
and content-length) may change during reformatting. In 40 
the event request variables change, the rules 408 are 
reevaluated, thereby generating a possibly different list 
of CRMs. In order to prevent looping, the context will 
only invoke CRMs from newly generated lists with a flag 
equal to WTV_CRM_PENDING. 45 
[0072] The context interface involves the following ten 
functions: PushData, Initialize, GetOrigContentLength, 
GetOrigContentType, GetCurContentLength, GetCur- 
ContentType, GetUserAgent, . GetClientCapabilities, 
SetCurContentLength, and SetCurContentType. so 
[0073] HRESULT PushData ([in] StreamType* pin- 
Stream, [in] StreamType* pOutStream, StreamSta- 
tusType* streamStatus). This function is called by the 
proxy server application to send data to and retrieve da- 
ta from the context. If the transformation is performed 55 
by non-streaming CRMs, then the proxy server applica- 
tion can expect to push data several times (until stream- 
Status = STREAM_END) before getting back any data. 



When the last PushData call returns, the entire file 
should be returned. For streaming transformations, data 
may be returned with each call to PushData. The 
streamStatus can have one of the following values: 1) 
Value STREAM_CONT which means that more data is 
expected; 2) Value STREAM_END which indicates the 
legitimate or expected end of data; and 3) Value 
STREAM_ERROR which indicates a premature or un- 
expected end of data and/or network failure. 
[0074] HRESULT Initialize ([in] unsigned int con- 
tentLength, [in] STRINGTYPE contentType, [in] 
STRINGTYPE userAgent, [in] ClientCapType* client- 
Caps, [in] Conf igType* curConf ig). This function is called 
by the CreateNewContext function. The context stores 
the first four arguments for future use by the proxy server 
application and CRMs. Each context maintains a pointer 
to the configuration with which it was created. That way, 
even if a new configuration is created during the course 
of a transformation, the transformation will continue to 
use the older configuration. 

[0075] The following six functions are used by the 
proxy server application to get original and updated re- 
quest variables: HRESULT GetOrigContentLength 
([out] unsigned int* origContcntLength); HRESULT Ge- 
tOrigContentType ([out] STRINGTYPE* origContent- 
Type); HRESULT GetCurContentLength([out] unsigned 
int* curContentLength); HRESULT GetCurContentType 
([out] STRINGTYPE* curContentType); HRESULT Ge- 
tUserAgent ([out] STRINGTYPE* userAgent); and 
HRESULT GetClientCapabilities ([out] ClientCapType** 
clientCaps). The following two functions are used by 
CRMs to update the request variables during a transfor- 
mation. Calling these functions with a value different 
from the original causes a reevaluation of the rules. The 
user-agent and client-caps do not change for a given 
request, so they do not have analogous "set" functions. 
The two functions are: HRESULT SetCurContentLength 
[in] unsigned int newContentLength); and HRESULT 
SetCurContentType ([in] STRINGTYPE newContent- 
Type). If any of the request variables are changed mid- 
transformation, it will lead to a reevaluation of the rules 
and a possible change in the pending module list. 

DECLARATION OF SUITABILITY 

[0076] Web content on remote server 118 is also 
cached in cache 414. When a client requests the web 
content, proxy server application 400 determines 
whether the cached web content is suitable for supply- 
ing back to the requesting client in lieu of retrieving the 
web content from the remote server 118 and supplying 
that newly retrieved web content back to the requesting 
client. In one example, first client 102 requests the web 
content. The proxy server 1 08 retrieves the web content, 
reformats the retrieved web content, stores the refor- 
matted web content in cache 41 4 and also forwards the 
reformatted web content back to the first requesting cli- 
ent 1 02. Second client 1 03 then requests the same web 
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content from the proxy server. If the web content cached 
is in an appropriate format for the client capabilities of 
the second client 103, then the proxy server should for- 
ward the cached web content back to the second client 
1 03 to speed the second client's access to the web con- 5 
tent. If, on the other hand, the web content cached is in 
a format inappropriate for the second client 1 03 (for ex- 
ample, the second client 103 will function in an undesir- 
able manner were it to attempt to decipher and/or use 
the web content as cached on cache 414), then the 10 
proxy server should not forward the cached web content 
as cached but rather should forward the web content in 
a suitable format for the requesting second client 103. 
The proxy server may either reform the cached web for- 
mat and then forward the reformatted web content to the is 
requesting client or the proxy server may retrieve the 
web content from the remote server, reformat the newly 
retrieved web content into the suitable format, and then 
forward that reformatted content back to the requesting 
client. 20 
[0077] The proxy server application 400 determines 
whether particular cached web content is suitable in one 
embodiment by storing particular information with the 
cached web content. When the first client requests the 
web content and the proxy server reformats that web 25 
content, the rules are evaluated as described above. 
Depending on the particular request variables of the re- 
quest and/or client capabilities determined for the re- 
quest, each individual rule evaluates to be either true or 
false. For each rule evaluated as true, an ordered list of 30 
CRMs to be used in the reformatting and input control 
parameters to control operation of the CRMs are gen- 
erated as described above in connection with Figure 5. 
This information, along with a pointer to the particular 
rules that were evaluated, is then cached in cache 414 35 
along with the reformatted web content. 
[0078] When second client 1 03 requests the web con- 
tent from the proxy server application, the request vari- 
ables and/or client capabilities for the second request 
are then used to evaluate the rules. As in the case of 40 
the first request, a list of CRMs and associated input 
control parameters are determined. To determine 
whether the cached web content is suitable for the sec- 
ond client 103, the proxy server application 400 com- 
pares the rules that evaluated as true, the list of CRMs 45 
to use, and the associated input control parameters as 
cached with the ones determined for the second re- 
quest. If the same rules are used, and if the same rules 
evaluate to true, then the cached web page is deter- 
mined to be suitable for passing on to the second client, so 
In such a case, the processing that would be performed 
for the second request would be the same as that for 
the first request. 

[0079] If, on the other hand, the ru les used or the rules 
that evaluated to true are not the same as those for the S5 
first request, then the web content is determined not to 
be suitable for passing on the second client. The web 
content is therefore reformatted in accordance with the 



list of CRMs and associated input control parameters as 
determined for the second request. 
[0080] Although this technique for determining suita- 
bility involves a reevaluation of the rules for the second 
request, other techniques are possible. In one suitable 
technique, the client capabilities of the requesting client 
are used to determine if the cached information is suit- 
able. For example, the x resolution, y resolution, and bit 
depth client capabilities of the second client 103 are 
used in one embodiment to determine whether a cached 
image having a particular resolution is suitable for the 
second client or whether the image should be reformat- 
ted before being supplied to the second client. 

EMAIL SERVER APPLICATION 

[0081] Although modular CRF and CRM reformatting 
software is described in connection with a proxy server 
application 400 in Figure 5, applications other than a 
proxy server application can use the modular CRF and 
CRM reformatting software. An email server application 
uses the modular CRF and CRM reformatting software 
in one embodiment to reformat an attachment on an 
email message into a format that the client can decipher. 
[0082] In a first step, an email message is received by 
a mail application running on server 108. The email 
message is stored in a mail store. Next, client establish- 
es a connection to server 108 and the email server. 
When this connection is established, the client passes 
information indicative of client capabilities to the email 
server. Actual client capabilities may be passed to the 
server or information indicative of client capabilities may 
be passed to the server and the server determines as- 
sociated client capabilities using a client capabilities da- 
tabase (CCD). The email server then retrieves the email . 
message for the client from the mail store, evaluates the 
rules using the client capabilities as input, and process- 
es the email message in a similar way to the way the 
HTML was processed in the example described above 
in connection with Figure 5. Only here, rfo processing 
needs to be done on the email message itself. Accord- 
ingly, no CRM is called. The email message is not 
passed back to the client immediately, rather processing 
is done on the attachment. The email server separates 
the attachment from the email message and then refor- 
mats the attachment. Similar to the way the image was 
reformatted in the example described above in connec- 
tion with Figure 5, a new context is created and the client 
capabilities of the client are used to determine which 
CRMs will process the attachment and what input con- 
trol parameters will be used to control operation of those 
CRMs; The data of the attachment is then pushed onto 
the appropriate CRMs for processing and the processed 
data is returned back to the context. Once the reformat- 
ting of the attachment is completed, the attachment is 
inserted back into the email message and the email 
message is sent to the client. If, for example, the client 
cannot decipher an attachment of a first image format 
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but can decipher images of a second image format, and 
if email for the client were to be received onto the email 
server where the email had an attachment in the first 
image format, then the email server would use the client 
capabilities to determine to reformat the attachment into . 5 
the second image format before forwarding the email 
back of the client. The client could therefore decipher 
the email attachment even though it could not have de- 
ciphered the original unreformatted attachment. In 
some embodiments, the email is reformatted and stored 10 
in the mail store in the reformatted form so that when 
the client established a connection and retrieves the 
email message, the client receives the reformatted 
email message. In other embodiments, the email is not 
stored in the reformatted format but rather is stored in 15 
the mail store in the original format. When the client re- 
quests the email, the email message is retrieved and 
reformatted then immediately prior.to be passed back 
to the client. 

[0083] Although the present invention is described in 20 
connection with certain specific embodiments for in- 
structional purposes, the present invention is not limited 
thereto. In some embodiments, the information indica- 
tive of client capabilities is actual client capabilities 
passed to the server from the requesting client, whereas 25 
in other embodiments the information indicative of client 
capabilities is information used by the server to deter- 
mine the client capabilities of the requesting client. In 
some embodiments, the proxy server receives a request 
variable (for example, user-agent) from the client but re- 30 
ceives other request variables (for example, content- 
length and content-type) from the remote server.. Con- 
ventional programming techniques other than the COM 
programming standard can be employed to realize the 
modular aspect of the modular server platform in ac- 35 
cordance with an aspect of the invention. Software that 
carries out steps of methods in accordance with the 
present invention can be stored on a computer-readable 
medium. Examples of computer-readable mediums in- 
clude magnetic and optical storage media and semicon- 40 
ductor memory. Accordingly, various modifications, ad- 
aptations, and combinations of various features of the 
described embodiments can be practiced without de- 
parting from the scope of the invention as set forth in the 
claims. 45 



Claims 

1. A method, comprising: so 

a. retrieving onto a proxy server content from a 
remote server, the proxy server comprising a 
first module and a second module; 

b. reformatting the content into first reformatted 55 
content using the first module and not using the 
second module; 

c. reformatting the content into second refor- 



matted content using the second module and 
not using the first module; 

d. receiving a request from a first client onto the 
proxy server for the content; 

e. supplying the first reformatted content to the 
first client from the proxy server; 

f . receiving a request from a second client onto 
the proxy server for the content; and 

g. supplying the second reformatted content to 
the second client from the proxy server. 

2. The method of Claim 1 , wherein the first module is 
a portion of executable code that is dynamically 
linked into the proxy server at a run time of the proxy 
server, and wherein the second module is a portion 
of executable code that is dynamically linked into 
the proxy server at the run time of the proxy server. 

3. The method of Claim 2, wherein: 

the supplying of the first reformatted content to 
the first client from the proxy server involves de- 
termining that the first reformatted content is to 
be supplied to the first client based at least in 
part on information indicative of client capabil- 
ities of the first client, the information indicative 
of client capabilities of the first client being 
present in the request from the first client, and 
the supplying of the second reformatted con- 
tent to the second client from the proxy server 
involves determining that the second reformat- 
ted content is to be supplied to the second client 
based at least in part on information indicative 
of client capabilities of the second client, the in- 
formation indicative of client capabilities of the 
second client being present in the request from 
the second client. 

4. The method of Claim 3, wherein the client capabil- 
ities of the first client includes an indication of an 
amount of memory storage space on the first client, 
and wherein the client capabilities of the second cli- 
ent includes an indication of an amount of memory 
storage on the second client. 

5. The method of Claim 3, wherein the client capabil- 
ities of the first client includes an indication of an 
amount of disk storage space on the first client, and 
wherein the client capabilities of the second client 
includes an indication of an amount of disk storage 
on the second client. 

6. The method of Claim 3, wherein the client capabil- 
ities of the first client includes an indication of a res- 
olution of a display of the first client.'and wherein 
the client capabilities of the second client includes 
an indication of a resolution of a display of the sec- 
ond client. 
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7. The method of Claim 3, wherein the client capabil- 
ities of the first client includes an indication of a per- 
formance of a connection to the first client, and 
wherein the client capabilities of the second client 
includes an indication of a performance of a con- 
nection to the second client. 

8. The method of Claim 7, wherein the connection to 
the first client is a dial-up connection, and wherein 
the connection to the second client is a dial-up con- 
nection. 

9. The method of Claim 7, wherein the connection to 
the first client is a DSL connection, and wherein the 
connection to the second client is a DSL connec- 
tion. 

10. The method of Claim 7, wherein the connection to 
the first client is a cable modem connection, and 
wherein the connection to the second client is a ca- 
ble modem connection. 

11. The method of Claim 3, wherein the client capabil- 
ities of the first client includes an indication of an 
amount of cache memory on the first client, and 
wherein the client capabilities of the second client 
includes an indication of an amount of cache mem- 
ory on the second client. 

12. The method of Claim 3, wherein the client capabil- 
ities of the first client includes an indication that the 
first client is enabled for a particular image data for- 
mat, and wherein the client capabilities of the sec- 
ond client includes an indication that the second cli- 
ent is enabled for a particular image data format. 

13. The method of Claim 3, wherein the client capabil- 
ities of the first client includes an indication that the 
first client is enabled for a particular audio data for- 
mat, and wherein the client capabilities of the sec- 
ond client includes an indication that the second cli- 
ent is enabled for a particular audio data format. 

14. The method of Claim 3, wherein the client capabil- 
ities of the first client includes an indication of a 
processor clock speed of the first client, and where- 
in the client capabilities of the second client includes 
an indication of a processor clock speed of the sec- 
ond client. 

15. The method of Claim 2, wherein: 

the supplying of the first reformatted content to 
the first client from the proxy server involves de- 
termining that the first reformatted content is to 
be supplied to the first client based at least in 
part on a request variable from the request from 
the first client, and 
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the supplying of the second reformatted con- 
tent to the second client from the proxy server 
involves determining that the second reformat- 
ted content is to be supplied to the second client 
based at least in part on a request variable from 
the request from the second client. 

16. A method, in a computer network system involving 
a first client, a second client, a proxy server, and a 
remote server, comprising: 

receiving onto the proxy server a first request 
from the first client for content from the remote 
server; 

obtaining first information indicative of capabil- 
ities of the first client; 

supplying the content reformatted in a first way 
from the proxy server to the first client; 
receiving onto the proxy server a second re- 
quest from the second client for the content 
from the remote server; 

obtaining second information indicative of ca- 
pabilities of the second client; and 
supplying the content reformatted in a second 
way from the proxy server to the second client. 



17. The method of Claim 16, wherein the proxy server 
includes a first module of dynamically-linkable exe- 
cutable code and a second module of dynamically- 

30 linkable executable code, the method further com- 
prising: 

using the first module to reformat the content 
from the remote server to generate the content 

35 formatted in the first way, the second module 

not being used to generate the content refor- 
matted in the first way; and 
using the second module to reformat the con- 
tent from the remote server to generate the con- 

40 tent formatted in the second way, the first mod- 

ule not being used to generate the content 
reformatted in the second way. 

18. The method of Claim 17, wherein the first informa- 
45 tion includes a first software build number, and the 

second information includes a second software 
build number. 

19. The method of Claim 17, wherein the first informa- 
so tion includes a software version number, and the 

second information includes a second software ver- 
sion number. 

20. The method of Claim 17, wherein in addition to the 
55 first information the proxy server receives an indi- 
cation of a content-type associated with the first re- 
quest, the proxy server using the indication of the 
content-type to determine to use the first module to 
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reformat the content in the first way.. 

and wherein in addition to the second infor- 
mation the proxy server receives an indication of a 
content-type associated with the second request, 
the proxy server using the indication of the content- 5 
type to determine to use the second module to refor- 
mat the content in the second way. 

21. The method of Claim 20, wherein the indication of 

the content-type associated with the first request is 10 
received by the proxy server in a response from the 
remote server, and wherein the indication of the 
content-type associated with the second request is 
received by the proxy server in a response from the 
remote server. 15 

22. The method of Claim 17, 

wherein the proxy server uses the information 
indicative of capabilities of the first client to de- 20 
termine client capabilities of the first client, the 
proxy server receiving request variable infor- 
mation associated with the first request, the 
proxy server using the client capabilities and 
the request variable information to determine 25 
to use the first module to reformat the content 
from the remote server, and 
wherein the proxy server uses the information 
indicative of capabilities of the second client to 
determine client capabilities of the second cli- 30 
ent, the proxy server receiving request variable 
information associated with the second re- 
quest, the proxy server using the client capa- 
bilities and the request variable information to 
determine to use the second module to refor- 35 
mat the content from the remote server. 

23. The method of Claim 22, wherein the request vari- 
able information associated with the first request is 

a content-type, and wherein the request variable in- 40 
formation associated with the second request is a 
content-type. 

24. The method of Claim 22, wherein the request vari- 
able information associated with the first request is 45 
a content-length, and wherein the request variable 
information associated with the second request is a 
content-length. 

25. The method of Claim 1 7, wherein the first informa- 50 
tion includes a client capability of the first client, and 

the second information includes a client capability 
of the second client. 

26. The method of Claim 17, wherein the first informa- 55 
tion includes an indication of a connection speed of 

a connection to the first client, and the second in- 
formation includes an indication of a connection 



speed of a connection to the second 

27. The method of Claim 17. wherein the first informa- 
tion includes an indication of a resolution of a dis- 
play of the first client, and the second information 
includes an indication of a resolution of a display of 
the second client. 

28. The method of Claim 17, wherein the first informa- 
tion includes an indication of an amount of memory 
on the first client, and the second information in- 
cludes an indication of an amount of memory on the 
second client. 

29. The method of Claim 16, wherein the proxy server 
comprises a tokenizer module and a tokenizer sub- 
module, the proxy server generating the content 
reformatted in the first way by: 

,■- 

causing the tokenizer module to process the 
content so as to output tokens; and 
causing the tokenizer sub-module to operate 
on the tokens. 

30. A proxy server, comprising: 

a first dynamically- linkable module that refor- 
mats content in a first way; 
a second dynamically-linkable module that 
reformats content in a second way; and 
means for retrieving content requested from a 
remote server by a client, and for determining 
whether to use either the first module or the 
second module to reformat the content request- 
ed, the means making the determination based 
at least in part on one of the group consisting 
of: a request variable and a client capability. 

31. The proxy server of Claim 30, wherein the means 
uses the one of the group to evaluate a set of rules 
and thereby to generate a list of modules to be used 
in reformatting the content requested from the re- 
mote server. 

32. The proxy server of Claim 31 , wherein the rules can 
be altered without altering or recompiling either the 
first module or the second module. 

33. The proxy server of Claim 32, wherein the one of 
the group is a client capability. 

34. The proxy server of Claim 32, wherein the one of 
the group is a request variable taken from the group 
consisting of: content-length, content-type, and us-, 
er-agent. 

35. A proxy server, comprising: 
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means for evaluating a set of rules to determine 
which of a plurality of ways to reformat content 
requested by a client; and 
means for changing the set of rules without rec- 
ompiling the means for evaluating the set of 5 
rules. 

36. The proxy server of Claim 35, wherein the means 
for changing receives a text file containing rule in- 
formation, the means for changing passing the rule 10 
information to the means for evaluating such that 
the set of rules is changed. 

37. The proxy server of Claim 35, further comprising: 

15 

a first dynamically-linkable module which when 
executed reformats content a first way; and 
a second dynamically-linkable module which 
when executed reformats content a second 
way, the means for evaluating determining if the 20 
first dynamically-linkable module or if the sec- 
ond dynamically-linkable module will reformat 
the content requested by the client. 

38. A system, comprising: 25 

a first modular proxy server coupled to the In- 
• temet and operated by a first operator, the first 
modular proxy server having a control portion, 
a first set of ru les, and a plurality of dynamically- 30 
linkable modules, the control portion determin- 
ing based on an evaluation of the first set of 
rules which of the plurality of dynamically-link- 
able modules of the first modular proxy server 
will process a particular web content; and 35 
a second modular proxy server coupled to the 
Internet and operated by a second operator the 
second modular proxy server having a control 
portion, a second set of rules, and a plurality of 
dynamically-linkable modules, the control por- 40 
tion determining based on an evaluation of the 
second set of rules which of the plurality of dy- 
namically-linkable modules of the second mod- 
ular proxy server will process a particular web 
content, the control portion of the first modular 45 
proxy server and the control portion of the sec- 
ond modular proxy server being substantially 
identical, the second modular proxy server con- 
taining a dynamically-linkable module that is 
not present in the first modular proxy server. so 

39. The system of Claim 38, wherein the second set of 
rules is different from the first set of rules, the sec- 
ond operator having altered the second set of rules, 

the second operator not having altered the first set 55 
of rules. 

40. The system of Claim 38, wherein one of the plurality 



of dynamically-linkable modules of the first modular 
proxy server is identical to one of the plurality of dy- 
namically-linkable modules of the second modular 
proxy server, and wherein another of the plurality of . 
dynamically-linkable modules of the first modular 
proxy server is not identical to any of the plurality of 
dynamically-linkable modules of the second modu- 
lar proxy server. 

41. The system of Claim 38, wherein the first modular 
proxy server comprises a tokenizer module, and a 
tokenizer sub-module, the tokenizer module con- 
verting web content into tokens, the tokenizer sub- 
module operating on the tokens. 

42. A method of customizing a modular proxy server, 
the modular proxy server having a control portion 
and a plurality of dynamically-linkable modules, a 
first of the plurality of dynamically-linkable modules 
reformatting content a first way, a second of the plu- 
rality of dynamically-linkable modules reformatting 
content a second way, the method comprising: 

generating a third dynamically-linkable module 
after the first and second dynamically-linkable 
modules are present on the modular proxy 
server; 

loading the third dynamically-linkable module 
onto the modular proxy server to be present on 
the modular proxy server along with the control 
portion, the first dynamically-linkable module 
and the second dynamically-linkable module; 
and 

using the third dynamically-linkable module 
with the control portion to reformat content re- 
quested by a client of the modular proxy server. 

43. The method of Claim 42 : further comprising: 

(a) before the generating of the third dynami- 
cally-linkable module, using the control portion and 
. at least one of the first and second dynamically-link- 
able modules to reformat content, 

wherein the generating of the third dynamical- 
ly-linkable module involves compiling code to ob- 
tain the third dynamically-linkable module without 
compiling the control portion, and wherein the using 
of the third dynamically-linkable module with the 
control portion involves executing the same control 
portion executed in (a), the control portion not being 
compiled after (a). 

44. A proxy server, comprising: 

a plurality of modules, a first of the modules 
reformatting content a first way, a second of the 
modules reformatting content a second way; 
software for determining, based on client capa- 
bilities of a requesting first client, which of the 
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plurality of modules to use in reformatting con- 
tent requested by the first client; and 
a cache containing the requested content along 
with an indication of which of the plurality of 
modules were used in reformatting the content 5 
requested by the first client. 

45. The proxy server of Claim 44, further comprising: 

software for determining, based on client ca- 
pabilities of a second requesting client, which of the 10 
plurality of modules to use in reformatting content 
requested by the second client, the software also 
determining whether the plurality of modules to use 
in reformatting content requested by the second cli- 
ent matches the stored indication of which of the is 
plurality of modules were used in reformatting the 
content requested by the first client, and wherein if 
it matches then the proxy server passes the content 
cached back to the requesting second client, but if 
it does not match then the proxy server retrieves the 20 
requested content from a remote server, reformats 
the retrieved content, and then passes the reformat- 
ted content back to the second client. 

46. The proxy server of Claim 45, wherein input control 25 
parameters for controlling operation of the modules 
used in reformatting the content requested by the 
first client are determined based on the client capa- 
bilities of the first client, and wherein these input 
control parameters are stored in the cache along 30 
with the requested content and the indication of 
which of the plurality of modules were used in refor- 
matting the content requested by the first client. 

47. The proxy server of Claim 46, wherein the software 35 
that determines which of the plurality of modules to 
use in reformatting the content requested by the 
second client determines input control parameters 
associated with the request of the second client, 
and wherein the content cached is only passed *o 
back to the requesting second client if the input con- * 
trol parameters determined for the request of the 
second client match the input control parameters 
stored in the cache. 

45 

48. A method, comprising: 

on a proxy server, performing an evaluation of 
a set of rules to determine which of a plurality 
of modules to use in reformatting content re- so 
quested by a first client; 

storing information indicative of an outcome of 
the evaluation of the set of rules, the informa- 
tion being stored in a cache on the proxy server 
in association with the content requested by the 55 
first client; 

on the proxy server, performing a second eval- 
uation of the set of rules to determine which of 



the plurality of the modules to use in reformat- 
ting content requested by a second client; 
obtaining information indicative of an outcome 
of the second evaluation of the set of rules: and 
comparing the information indicative of the out- 
come of the second evaluation with the infor- 
mation indicative of the evaluation of the rules 
stored in the cache, wherein if the comparing 
indicates that the information indicative of the 
outcome of the second evaluation is identical 
to the information indicative of the evaluation 
stored in the cache then the content stored in 
the cache is supplied to the second client, but 
. if the comparing indicates that information in- 
dicative of the outcome of the second evalua- 
tion is not identical to the information indicative 
of the evaluation stored in the cache then the 
proxy server reformats the content consistent 
with the information indicative of the second 
evaluation and then passes the content so 
reformatted back to the second client. 

49. A method, comprising: 

a. receiving onto an email server an email mes- 
sage having an attachment, the email message 
being addressed to a client, the attachment be- 
ing in a first format, the client not being able to 
decipher attachments in the first format but be- 
ing able to decipher attachments in a second 
format; 

b. receiving onto the email serverfrom the client 
information indicative of client capabilities of 
the client; 

c. the email server using the information indic- 
ative of client capabilities to reformat the at- 
tachment into the second format; and 

d. the email server supplying the email mes- 
sage and the attachment in the second format 
to the client, 

50. An email server, comprising: 

means for reformatting, based on information 
indicative of client capabilities of a client, an 
email attachment from a first format into a sec- 
ond forrnaL the client being unable to decipher 
attachments in the first format, the client being 
able to decipher attachments in a second for- 
mat; and 

means for supplying the email attachment in 
the second format to the client. 

51. The email server of Claim 50, wherein the means 
for reformatting is a page patcher module. 

52. The email server of Claim 50, wherein the means 
for reformatting comprises a tokenizer module and 
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a tokenizer sub-module, the tokeni7er module con- 
verting the attachment into tokens, the tokenizer 
sub-module operating on the tokens. 
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if ( content-type = "JPEG" & screen = "TV" ) 
{ 

ImageCRM ( jpeg_qualify = 55, jpeg_smooth = TRUE, 
xres = 800, yres = 600, jpeg_entropy_optimize = TRUE ); 
} 

if ( content-type = "JPEG" & screen = "monitor" ) 
{ 

ImageCRM ( jpeg_quality = 70, jpeg_smooth = FALSE, 
xres = 1024, yres = 768, jpeg_entropy_optimize = 
TRUE ); 

} 

if ( content-type = "JPEG" & client = "Foo2.2" ) 
{ 

ImageCRM ( forced-format = "GIF" ); 

// Foo2.2 client has problems with JPEG decoding 

} 

if ( content-type = "JPEG" & client = "PalmPilot" ) 
{ 

ImageCRM ( jpeg_quality = 50, jpeg_colorspace = 
"greyscale", xres = 200, yres = 300 ); 

} 

FIG. 6 
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